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Introduction 


Decision Support Systems (DSS) represent a concept of the role of computers within the deci- 
sion making process, The term has become a rallying cry for researchers, practitioners, and 
managers concerned that Management Science and Management Information Systems fields have 
become unnecessarily narrow in focus. As with many rallying cries, the term is not well defined. 
For some writers, DSS simply mean interactive systems for use by managers. To others, the key 
issue is support, rather than system. They focus on understanding and improving the decision pro- 
cess; a DSS is then designed using any available and suitable technology. Some researchers view 
DSS as a subfield of MIS, while others regard it as an extension of Management Science techniques. 
The former define Decision Support as providing managers with access to data and the latter as giv- 
ing them access to analytic models. 


The key argument of this paper is that the term DSS is relevant to situations where a "final" sys- 
tem can be developed only through an adaptive process of learning and evolution. The design stra- 
tegy must then focus on getting finished; this is very different from Management Science and Data 
Processing approaches. The research issues for DSS center around adaptation and evolution; they 
include managerial learning representation of tasks and user behavior, design architecture and stra- 
tegies for getting started. 


DSS Redefined 


The argument for adaptive design as the key element of DSS is drawn from an analysis of the 
early DSS literature, and an analysis of the characteristics of 30 case studies[1] described more fully 
in the Appendices. It can be argued that what Gorry and Morton (1971) present, and Gerrity 
(1971), Morton (1970), Stabell (1977), and Keen and Morton (1978), later extend, is not the gen- 
eral case, but a special one. The following definition of Support System meshes the task-centered 
perspective into that of adaptive design and also picks up on the most interesting finding from the 
case studies, the unpredictability of DSS usage: The label "Support System" is meaningful only in 
situations where the "final" system must emerge through an adaptive process of design and usage. 
This process may be needed for a variety of reasons: 


(1) The designer or user cannot provide functional specifications or is unwilling to do so. A "semi- 
structured” task is such an instance; we either lack the necessary knowledge to lay out procedures 
and requirements (i.e. the degree of structure is perceptual) or feel that such a statement can never 
be made (i.e. the lack of structure is intrinsic to the task). 


(2) Users do not know what they want and the designers do not understand what they need or can 
accept; an initial system must be built to give users something concrete to react to. 


(3) Users’ concepts of the task or decision situation will be shaped by the DSS. The system stimu- 
lates learning and new insights, which in turn stimulate new uses and the need for new functions in 
the system. The unpredictability of DSS usage surely reflects this learning, which can be exploited 
only if the DSS evolves in response to it. 


(4) Intended users of the system have sufficient autonomy to handle the task in a variety of ways, or 
differ in the way they think to a degree that prevents standardization. In this situation, any com- 
puter support must allow personalized usage and be flexible. 


While (3) states that the DSS shapes the user, (4) equally suggests that the user shapes the DSS. 
This idea makes DSS a necessary concept. For any given system development effort, it makes a 
great deal of difference whether or not the implementors view it as requiring a DSS as opposed to a 
marketing model, retrieval system, report generator, etc. It would be a severe mistake to rely on 
traditional development techniques if the final system will evolve only through the ongoing 
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interaction between user and designer, learning, personalized use, or the evolution of new functions. 
Learning, adaptation, and evolution are made feasible by building a "DSS" and not a "model". If 
these are not needed for effective development and use of a system, then one should build it as a 
"model" in the traditional way and the new label is not relevant. 


This definition of DSS in terms of adaptive design and use provides a base for a research frame- 
work that is consistent with the empirical findings of the case studies and that integrates the concep- 
tual issues they raise or reflect. There seem to be three overall issues for a theory of DSS: 


(1) understanding the dynamics of the adaptive relationship between user, designer and technical 
system; 
(2) analyzing tasks in relation to users’ processes and criteria for system design; 


(3) developing an organizational focus to complement the cognitive perspective and thus include 
Organizational as well as Personal Support Systems. 


Adaptive Development and Use 


Figure 1 shows the adaptive links between the major actors involved in any DSS development 
and the technical system. The arrows represent a direction of influence. For example, 
SYSTEM—> USER indicates that learning is stimulated by the DSS while USER—->SYSTEM 
refers to the personalized, differentiated mode of use that evolves. The two adaptive processes work 
together: an effective DSS encourages the user to explore new alternatives and approaches to the 
task (S—>U). This in itself stimulates new uses of the system, often unanticipated and idiosyn- 
cratic (U—S). 
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Figure 1: An Adaptive Framework for DSS 


The arrows are not merely a convenient schematic. They help clarify whether a particular sys- 
tem should be called a DSS. For example, an airline reservation system is technically similar to 
many retrieval-based DSS. However, this is not intended to stimulate learning (S+~>U), nor are 
there personalized modes of usage; there is a "right" way to use the system and the user must adjust 
to it, not vice versa (U-+->S). Similarly an interactive planning model that is used to assess a 
predetermined range of alternative is a system for solutions, not for learning. It need not be flexible 
and adapt to the user (U-+-=S). 


The arrows also represent requirements for successful DSS development and use. For example, 
if the system forces users to follow a fixed set of procedures, learning can not be exploited: 
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In effect the DSS contains its own obsolescence. It stimulates new approaches which in turn it inhi- 
bits. 

The definition of DSS as applicable in situations where the final system must evolve from adap- 
tive development and use thus implies: 
(1) A system is a "DSS" only if each of the arrows is relevant to the situation 


(2) Where they are relevant, the design process must insure they are not blocked by inflexible 
design structures, failure to allocate resources for implementing new functions, or lack of a direct 
relationship between user and designer. 


(3) Each arrow represents a distinctive aspect of research and practice. 


Figure 1 ignores the context of the DSS development process, especially the task to be supported 
and the wider organization. Before expanding it, however, it seems useful to discuss each adaptive 
link in relation to DSS research. There are three loops: 
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This, in the context of Personal Support Systems, may be termed the cognitive loop. (The issue of 
organizational support will be discussed separately). The link S—+U concerns managerial learning 
and U—->S the individuals’ exploitation of the DSS capabilities and/or their own learning. The 
cognitive loop helps explain the consistent finding in the case studies that individuals use a given 
DSS in very different ways and that uses are so often unintended and unpredicted. This seems a 
natural outcome of the sequence S—»>U—>S—~+U .... 


Much early DSS research explored aspects of the cognitive loop, particularly characteristics of 
individual problem-solving that influence the use of a DSS. This was a fairly static analysis and it 
seems essential to examine the managerial (and organizational) learning process in more detail. 
Doing so requires richer theoretical models; the early research drew on limited concepts of cognitive 
style and cognitive structure, that were at too high a level of analysis to track the learning process. 
They focused on general aspects of the psychology of of individual differences (Stabell, Carlisle, 
Grochow). 


The User-Builder Link 
The link 
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is the implementation loop. 


(a) U—>B highlights a key aspect of adaptive design, discussed by Ness and Courbon, et al. Ack- 
off long ago pointed out that users do not know what they need. The middle-out approach relies on 
the quick delivery of an initial system to which users can respond and thus clarify what they really 
want. Middle-out design is the means by which the designer learns from the user; it also insures 
that the user drives the design process. 
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(b) B—~>U: this link has been explored in studies of DSS implementation that examine the role of 
the “integrating agent" (Bennett), intermediary (Keen), chauffeur (Grace), and change agent 
(Ginzberg). DSS are a service rather than a product and require that the designer understand the 
users’ perspective and processes, build credibility and be responsive to their evolving needs. 


The implementation loop is both well researched and well understood, The empirical work of 
Courbon, Grajew, and Tolovi is an exhaustive and precise test of the concepts of adaptive design. 
The more diffuse discussions of implementation are less operational (Bennett, Keen, Ginzberg, and 
Scott Morton). 


The System-Builder Link 
The evolution loop 
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is less easy to label than the others. While the case studies show again and again that DSS evolve 
and much of the conceptual work relevant to DSS recommends evolutionary development (Urban), 
there are few detailed, longitudinal studies or theoretical models. It is perhaps the easiest to view 
the links in relation to the other loops. Managerial learning (S—>U) and personalized uses (U— 
->S) put strain on the existing system. This builds pressure for evolution (S—->B). New functions 
are then provided (B—=S). The case studies imply that this is not a continued, evenly paced pro- 
cess, but occurs in discrete phases (see also Andreoli and Steadman). Users explore the initial sys- 
tem for a while and gradually become confident with it. At a certain point, it becomes apparent 
that a new function needs to be added to the system. Quite often, usage does not really take off 
until this extension is provided; the "new" system leads to very different volumes and modes of use 
than the earlier one (Andreoli and Steadman). 


The S—->B link needs research. Keen and Gambino have employed the common device of a 
data trap to track individuals’ use of a DSS[4] (see also Stabell, Andreoli and Steadman), in terms 
of emerging patterns and "command sequences". The argument is that users initially use the com- 
mands of the DSS as single words (e.g., "LIST", "REGRESS"), but later develop, largely via the 
adaptive processes of the cognitive loop, what are effectively sentences; they use consistent 
sequences of commands and build up their own analytic routines. This process is easy to identify, 
the hypothesis is that it triggers demand for readiness to use new commands. 


The other link, B—->S, is easier to explain. It simply involves the designer adding new capa- 
bilities to the DSS. This obviously is feasible only 


(a) if the design architecture is modular, flexible, and easily modified 
(b) the programmer can implement new functions cheaply and quickly; 
(c) the designer maintains ongoing contact with the users. 


The advocates of APL as "the" language for DSS (Contreras, Keen), of end-user languages 
(Keen and Morton), and “command driven” interfaces all emphasize the need for program structures 
and programming methods to facilitate evolution. The case studies indicate that the success of a 
DSS often depends on its evolution rather than its initial use, and on fast, responsive implementa- 
tion. 


Discussions of DSS evolution focus on new functions and commands. There is relatively little 
exploration of the evolution of data and data structures. Model-based DSS seem both easier to 
build and evolve than do data-based ones. DSS research currently lacks a focus on handling data 
management issues. 


Summary of Adaptive Links 


There is not room here to discuss each adaptive link in Figure 1 in any detail. The preceding 
summary covers only a few issues relevant to research. Hopefully, Figure 1 constitutes a definition 
of DSS development that clarifies what a DSS is and is not, and what actions and processes it 
involves. Each arrow represents a clear research area relevant to DSS practice. 
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The Task Context 


Figure 1 ignores the task to be supported. Obviously, a DSS can be built only if the designer 
understands the task at a level of detail sufficient to: 


(a) relate the task to the users’ processes; 
(b) design the functions of the DSS; 
(c) by extension, relate the users’ processes to the DSS functions. 


At present, methodologies for describing tasks, user processes and system functions are at too 
high a level to integrate all three components.[3] For example, one may classify an individual in 
terms of cognitive style (e.g., intuitive vs. systematic), classify the task as semi-structured and the 
system as an interactive retrieval system. This provides no link between task characteristics and 
detailed design criteria and user behavior. DSS research needs to find a level and method of 
representing tasks that permits this link. Such a method does not yet exist. Hackathorn’s and 
Meldman’s use of networks comes closest but is not intended as a general methodology for DSS. 


The ideas presented below require a major research effort before they can be validated and 
made operational. In a way, they pick up on Gorry and Mortin’s discussion of "semi-structured" 
tasks, at a more molecular level: 


(1) The tasks a DSS addresses involve some degree of discretion, inference and selection of informa- 
tion; if this is not so, there are no adaptive links between user and system 
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A whole task is composed of subtasks. The whole task may be the university admissions decision, 
portfolio management, media selection, etc., etc. The subtasks are discrete intellectual operations, 
such as calculating a sum, searching for a value, or comparing to two variables on a graph. 


(2) The subtasks identify the potential functions for the DSS, e.g., CALC, FIND, COMPARE. 


(3) User behavior and user learning can be described in terms of the sequence of and change in sub- 
tasks, 


(4) Use of the DSS can be treated in relation to the functions. 


This level of representation has several practical and conceptual merits. It also suggests that 
DSS should be command-driven. Keen and Alter argue that the commands‘correspond to the users’ 
verbs (e.g.,"list", "graph"). Keen adds that if a function in a system does not relate directly to some 
concept in the users’ mind, it really cannot be used. Carrying out a task involves a sequence of 
verb-related subtasks (do this, do that, etc.). Using a DSS involves invoking a sequence of verb- 
based commands. Evolving it means adding new commands. Learning is identifiable only in terms 
of use of new commands or redefinition of existing ones, and personalized use is apparent from the 
choice of commands. 


In a structured task, the subtasks can be clearly specified and the sequence in which they are 
invoked predicted. A "semi-structured" task is thus one where either not all the subtasks can be 
represented and hence translated into DSS commands or they can be represented but the sequence 
not predicted. Focusing on subtasks, rather than whole tasks, retains the intuitive appeal of the 
Gorry-Morton framework but eliminate problems of definition. In addition, doing so addresses 
Stabell’s point, that a whole task is usually socially-defined; two universities may handle the admis- 
sions process--the whole task--very differently, but it will have common subtasks. 


Keen and Morton, building on Gerrity and Stabell, discuss DSS design as a balance between 
descriptive and prescriptive understanding of the decision process. Supporting users implies provid- 
ing commands that correspond to their existing (or at least desired) verbs. Improving the effective- 
ness of their decision making means identifying new cornmands and stimulating their use through 
the adaptive processes described by Figure 1. 


A number of DSS researchers share this focus on subtasks. Blanning outlines the equivalent of 
a generative grammar for DSS that goes beyond verbs. Keen and Gambino suggest that most whole 
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tasks require a common set of verbs; almost any DSS needs such functions as Graph, List, Select, 
and Descrike (provide descriptive statistics). Henderson et. al. have designed a set of experiments 
on DSS use which track user behavior at the command and subtask level.(4] 


The ideas presented above are tentative and a proposal for research rather than a conclusion 
from it. The central postulate is that adaptive design and use of DSS, DSS evolution, managerial 
learning, etc. require a decision research process where the level of analysis is at the subtask level. 
Much of the vagueness of DSS concepts disappears when this is provided. Of course, the research 
issue is how to represent the subtasks. Contrearas, following on Berry, argues that they are linguist- 
ically at the level of APL functions, which can further be broken down into primitives. Blanning 
adopts a similar perspective. 


Figure 2 adds the task dimension to the adaptive loops. Whatever methodology or theoretical 
model of task structure and performance is used, it is obvious that the representation only can be at 
the subtask level if it is to translate an understanding of how the users think, and an assessment of 
how their performance can be made more effective into specific functions in a DSS. 
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Figure 2: Task Context 
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Contextual Issues in DSS Development 


Figure 3 expands Figure 2 to include contextual forces. The additional links are not so much 
adaptive influences as limiting ones. For example organizational procedures may constrain user dis- 
cretion and behavior (O—>U). In several of the case studies, DSS were not used effectively 
because the organization’s control, communication and reward systems provided no incentive. 
Clearly, the extent to which organizational procedures affect individuals in a given task determines 
whether the situation requires a Personal, Group, or Organizational Support System. In turn, the 
extent to which user(s) can influence the procedures (U——> 0) limits the organizational learning a 
DSS can stimulate. 


In a similar fashion, the DSS itself is constrained by the organization’s available technology 
(T—-=S). This includes data as well as computer power, and the base of reliable operational sys- 
tems and technical expertise on which a DSS is built. The case studies mainly describe successful 
systems but there are several suggestions that DSS will not take root in an organization that has not 
yet provided managers with standard data processing and reporting systems. In such situations, DSS 
are seen as a luxury or as irrelevant. 
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Figure 3: Organizational Issues 
The link S—~+>T is a reminder that learning and evolution can be blocked by the inability to 
obtain additional technology. Keen and Clark found that the use of their DSS for state government 
policy and analysis was strongly constrained by states’ existing technology and procedures for operat- 
ing it. In addition, managerial learning and evolution of the DSS may require new data and struc- 
tures or lead to an overloading of the organizations time-sharing computer. The whole adaptive 
process in Figure 3 breaks down when any influence is absent or blocked. 


The final contextual issues addressed by Figure 3 is the charter for the builder. The implemen- 
tation loop relies on facilitation and middle-out design. This requires a close relationship between 
user and builder, which may not be feasible if: 


(1) the two groups are geographically or psychologically isolated; 
(2) the designers are a part of a unit, uch as Data Processing, with no mandate for innovation; 


(3) the organizations charge-out policies and procedures for project justification discourage explora- 
tion and require "hard" benefits. Keen points out that DSS often provide mainly qualitative bene- 
fits. They “improve” a decision process and it is unlikely that one can point in advance to a 
"bottom-line" payoff, especially if the value of the system is in the end determined by an adaptive, 
evolutionary process. 


Many DSS builders are either consultants or academics, who can be brought into an organiza- 
tion by the user and thus have relative freedom to define their role. A major constraint on develop- 
ing a DSS capability may be the lack of a suitable organizational charter. 


Conclusion 


The additions to the earlier schema made in Figure 3 address the question of Organizational 
Support Systems raised earlier and left hanging. Figure 1 provides a complete research framework 
for Personal Support Systems. Figure 3 is far more tentative. Substantial research on organizational 
issues for DSS is needed, and no effort will be made here to justify or elaborate on this preliminary 
identification of organizationa forces constraining DSS. The more important point is that Figure 1, 
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and the definition of DSS it reflects, seem to provide a robust and adequately precise framework for 
DSS research. The representation of subtasks indicates a theoretical, if not yet practical, methodol- 
ogy for studying and building DSS. 


If the framework presented here is valid, then Decision Support is a meaningful and indepen- 
dent discipline. The existing research base is fairly strong in certain areas, especially the implemen- 
tation loop. There are more than enough case studies available to point up issues, such as the 
nature of managerial learning and DSS evolution, that should be explored at a more precise level, 
often through laboratory experiments. The major conceptual problems concern subtask representa- 
tion, and a theoretical base for Organizational Support Systems. The term “Decision Support Sys- 
tems" is an excellent rallying cry. “Decision Support" can be an equally outstanding field of study. 


Appendix 1 -- Case Studies of DSS 
Three references contain most of the case-based descriptions used for the review in this paper: 


(1) Keen and Scott Morton, Decision Support Systems: An Organizational Perspective, 1978, This 
represents the orthodox faith. It includes fairly detailed descriptions of seven DSS. It excludes 
(largely because it filters the world through MIT-colored glasses, but also because of the long lead 
time between writing and publishing), the work of Grajew, Courbon, and Tolevi, and most of that 
done at Wharton by Ness and Hurst. It has a comprehensive bibliography. 


(2) Carlson, Eric D. (Editor), Proceedings of a Conference on Decision Support Systems, (1977), 
This contains very little conceptual material and emphasizes real-world applications. It has a strong 
“show-and-tell" flavor. Whereas Keen and Scott Morton use case descriptions to illustrate the con- 
cepts of a DSS, in this volume practitioners demonstrate their view of what aspects of concept have 
practical value. It seems clear that on the whole they do not share Keen and Scott Morton’s 
emphasis on the cognitive characteristics of the individual decision maker but focus instead on 
organizational processes. 


(3) Alter, Decision Support Systems: Current Practice and Future Challenges, (1979). This book is 
based on case studies on 56 systems, only a few of which are DSS. There are seven detailed studies, 
Some of which overlap with Keen and Morton, and Carlson ef al.Alter is partly concerned with 
‘sharpening the practical definitions of DSS by looking at innovative systems in general. He uses the 
term Decision Support System fairly loosely, mainly since his is an exploratory study which specifi- 
cally asks if it is useful to identify a system as a DSS. 


A fourth study, by Grajew and Tolovi describes three experimental DSS projects. Le Moigne 
criticizes Keen and Morton’s book as "partial et partiel'--incomplete and limited to the US experi- 
ence. He feels that French researchers are more advanced than the Americans. Certainly the work 
of Courbon, Grajew, and Tolovi builds on earlier research imaginatively and effectively. 


Results 
Some clear and general conclusions can be drawn from an examination of the studies: 


(1) The actual uses of DSS are almost invariably different from the intended ones; indeed, many of 
the most valued and innovated uses could not have been predicted when the system was designed. 


(2) Usage is personalized; whether a system is recently operational or has been in place for some 
time, there are wide variations among individuals in how they use its functions. 


(3) DSS evolve; case studies frequently state that key factors explaining successful development are a 
flexible design architecture that permits fast modification and a phased approach to implementation. 
(4) The functions DSS provide are generally not elaborate; complex systems evolve from simple 
components. 


(5) While the orthodox (academic) faith views DSS as tools for individual decision makers,[5] users 
regard the concept as more relevant to systems that support organizational process. They also feel 
they do not really use DSS for decision making. 


(6) Major benefits identified by users are flexibility, improved communications (of, for example, the 
logic of an analysis), insight and learning. 
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(7) DSS are frequently used by managers through intermediaries and chauffeurs; while an interac- 
tive computer system is essential for ease of access, there is little interactive problem-solving. Exam- 
ples of all these points are shown in Appendix 2. 


The Cases 


In the list below, the major sources of reference are identified as K-M (Keen and Morton), C 
(Carlson), and A (Alter). 


AAIMS: An Analytic Information System (C and A) 

BIS: Budget Information System (A) 

BRANDAID: (K-M) 

CAUSE: A Computer Assisted Underwriting System at Equitable (A) 
CIS: Capacity Information System (K-M) 

EIS: Executive Information System (C) 

GADS: Geodata Analysis Display System (K-M) 

GMIS: Generalized Management Information System (K-M) 
GPLAN: Generalized Planning (C) 

ISSPA: Interactive Support System for Policy Analysis (private paper) 
IMS: Interactive Marketing System (A) 

IRIS: Industrial Relations Information System (C) 

MAPP: Managerial Analysis for Profit Planning (C) 

PDSS: Procurement Decision Support System (International Harvester, private paper) 
PMS: Portfolio Management System (K-M and A) 

PROJECTOR: (K-M) 

REGIS: Relational Generalized Information System (C) 


Appendix 2 


1. Unanticipated Uses: 

PMS-- intended use, investment decisions tool; actual use, marketing tool and customer relations. 
MAPP-- intended use, financial planning; actual use, revealed branch bank irregularities. 
PROJECTOR -- intended use, analyzing financial data to answer preplanned questions; actual use, 
alerted users to new issues and unplanned questions. 


2. Personalized Uses: 

GADS -- public officials (police and school system users) could imagine solutions and then use 
GADS to test hypotheses; individual users’ values placed on variables led to entirely different con- 
clusions. 

REGIS -- encouraged data browsing, discerning new relationships and questions. 

PMS -- wide variance in function combinations used by individual managers. 


3. Evolution: 

BIS -- initial system modular in structure, database separate from applications program, new pro- 
grams added incrementally without upsetting data base. 

PMS -- initial prototype followed by full implementation, doubled number of programs in six 
months. 

CAUSE -- four evolutionary versions, deliberate emphasis on phased development to build credibil- 
ity and capability, routines increased from 26 to 200 during evolutionary period. 


4, Simple Functions: 

AAIMS -- 60 verb-like commands used, DISPLAY, PLOT, QUARTERLY, CHANGE,.. 
ISSPA -- DESCRIBE, EQUITY, REGRESS, HISTO, RANK, NTILES.,... 

PMS -- SCATTER, SCAN, STATUS, TABLE, GRAPH, SUMMARY, GROUBP.... 


5, Organizational Support Systems: 

CAUSE -- supports underwriting process, including data definition and collection. 
PDSS -- stabilizing purchasing agents’ ordering system. 

IRIS -- supports operations control in industrial relations applications 


£94 


6. Benefits: 

CAUSE -- reduced need for employer specialization, increased possibilities of internal reorganiza- 
tion, gave opportunity to newer employees. 

PROJECTOR -- time effectiveness improved “by a factor of 20", forced consideration of related 
issues, “confidence-inspiring” analysis. 

MAPP -- better product definitions and costing allocation, promoted internal learning. 

7. Intermediaries: 

GADS -- chauffeur used as a teacher and a translator, used to save time to get as many possible 
solutions as quickly as possible. 

IMS -- 50% of use by junior researcher with no decision making authority intermediary used only to 
push buttons, not make decisions. 

PMS -- secretaries operate, managers specify desired output. 


Notes 


1. The analysis is contained in a report by Keen, "A Review of DSS Case Studies", now in draft 
form. 


2, Methlie and LeMoigne have drawn attention to this and point out that Keen and Morton entirely 
ignore data management issues. 


3. Stabell has developed a range of techniques for decision research, at several levels of analysis. 
However, they focus on task and individual, and do not as yet include any DSS design criteria. 


4, Henderson, Gambino, and Ghani, private communication. 


§. Keen and Scott Morton’s book on DSS is mistakenly subtitled "An Organizational Perspective". 
The authors herewith recant. 


Bibliography 

Ackoff, R.L., "Unsuccessful Case Studies and Why", Operations Research, Vol. 8, No. 4, pp 259- 
263, March-April. 1960. 

Alter, S.L., Decision Support Systems: Current Practice and Continuing Challenges, Addison- 
Wesley, 1980. 

Andreoli, P. and Steadman, J., "Management Decision Support Systems: Impact on the Decision 
Proces", Master’s thesis, M.I.T., 1975. 

Anthony, R.N., Planning and Control Systems: A Framework for Analysis, Cambridge, MA, Har- 
vard University Graduate School of Business Administration, Studies in Management Control, 1965. 
Bennett, J., “Integrating Users and Decision Support Systems", in J.D. White (ed.), Proceedings of 
the Sixth and Seventh Annual Conferences of the Society for Management Information Systems, pp. 
76-86, Ann Arbor, University of Michigan, July, 1976. 

Berger, P., and F. Edelman, "IRIS: A Transaction-Based Decision Support’ System for Human 
Resources Management”, Database, Winter, 1977, Vol. 8, No. 3. 

Berry, P., "The Democratization of Computing", Paper presented at Eleventh Symposium Nacional 
de Systemas Computacionales, Monterrey, Mexico, March 15-18, 1977. 

Blanning, R., 'The Decision to Adopt Strategic Planning Models", Wharton School working papers, 
1979, 

Brooks, F.P., The Mythical Man-Month, Reading, MA, Addison-Wesley, 1975. 

Carlisle, J. "Cognitive Factors in an Interactive Decision Systems", Ph.D. dissertation, Yale Unive- 
sity, 1974. 

Carlson, E.D., and J.A. Sutton, A Case Study of Non-Programmer Interactive Problem-Solving, 
San Jose, California, IBM Research Report RJ1382, 1974. 

Contreras, L., "Decision Support Systems and Corporate Planning", Informal Communication, 1978. 
Courbon, J.C., J. Grajew, and J. Tolovi, “Design and Implementation of Interactive Decision Sup- 
port Systems: An Evolutive Approach". 

Gerrity, T.P., Jr., ‘The design of Man-Machine Decision Systems", Ph.D. dissertation, M.L.T., 
1970. 


GG 


Ginzberg, M.J., "A Process Approach to Management Science Implementation" Ph.D. dissertation, 
M.I.T., 1975. 

Gorry, G.A., and M.S. Scott Morton, "A Framework for Management Information Systems", Sloan 
Management Review, Vol. 13, No. 1, pp. 55-70 Fall, 1971. 

Grace, B.F., Training Users of Decision Support Systems, San Jose, California, IBM Research 
Report RJ1790, May 1976. 

Grochow, J.M., "Cognitive Style as a Factor in the Use of Interactive Computer Systems for Deci- 
sion Support", M.LT., 1974. 

Hackathorn, R.D., “Research Issues in Personal Computing”, Proceedings of the National ACM 
Conference, Washington, December 1978. 

Keen, P.G.W., “Computer Systems for Top Managers: A Modest Proposal", Sloan Management 
Review, Vol. 18, No. 1, pp. 1-17, Fall 1976. 

Keen and Clark, "Simulations for School Finance, a Survey and Assessment" Research Report to 
Ford Foundation, November, 1979. 

Keen and Gambino, "Mythical Man-Month Revisited", CISR working paper, January, 1980. 

Keen and M.S. Scott Morton, Decision Support Systems: An Organizational Perspective, Addison- 
Wesley, 1978. 

Keen and Wagner, “Implementing Decision Support Systems Philosophy", Datamation, November 
1979. 

Meldman, J. "Decision Support Systems for Legal Research", Paper presented at the II Symposium 
Nacional de Systemas Computacionales, Monterrey, Mexico, March 15-18, 1977. 

Morton, M.S. Scott, Management Decision Systems: Computer Based Support for Decision Making, 
Cambridge, MA: Division of Research, Harvard, 1971. 

Ness, D.N., "Decision Support Systems: Theories of Design", Paper presented at the Wharton Office 
of Naval Research Conference on Decision Support Systems, University of Pennsylvania, Philadel- 
phia, Pennsylvania, November 4-7, 1975. 

Simon, H.A., "A Behavioral Model of Rational Choice", In H.A.Simon, Models of Man, pp. 241- 
260, New York: Wiley, 1957. 

Stabell, C., "Decision Research: Description and Diagnosis of Decision Making in Organizations", In 
D. Heradstreit and O. Narvesen (eds.), Decision Making Research: Some Developments, Oslo, Nor- 
way: Norsk Utenriks Politisck Institute, 1977. 


Acknowledgement 


Many of the ideas expressed in this paper belong as much to my colleagues at the Wharton 
School, 1978-79, as to myself. In particular, the concepts of task representation were developed by 
Gary Hurst, Dick Hackathorn, and myself, and extended through discussions with John Henderson 
and Tom Gambino. The research framework owes much to a seminar on DSS run by Dick 
Hackathorn. 


ERRATA 


p. 1: the journal name ‘Data Base’ should have been italicized ‘Data Base’ 

p. 2: DSS should have been described as ‘loosely defined’, not ‘loosely designed’. 

p. 3: in line 7 ‘of should be ‘and’. 

p. 6: in line 3 ‘three’ should be ‘two’, and in line 14 ‘Greenfield’ should be ‘Greenfeld’. 


p. 24: in line 13 ‘References’ should be ‘Notes’, and the citation was omitted to ’Carlson, Eric D., (editor), 
Proceedings of a Conference on Decision Support Systems, Data Base, Vol. 8, No. 3, (Winter, 1977)’. 


p. 33: in the fourth paragraph, ‘yield’ should be ‘yield answers’. 

p. 25: Hurst’s first name ‘Gerry’ was misspelled as ‘Gary’. 

p. 37: The third paragraph should begin ‘This graphical version of a bow-compass method’. 
p. 38: In the third paragraph, ‘user-driver’ should be ‘user-driven’. 

pp 63-69: Several minor headings should have been underlined. 


p. 68: The last sentence should be: ‘Specific DSS’s will not be included in the model, only general 
capabilities, such as those listed in the outer columns of Figure 2.’. 


p. 69: In Figure 1, the axes pointing towards the top, the right and the left should be labelled ‘Perform- 
ance variables’, ‘Management variables’, and ‘Structural variables’ respectively. The caption should refer 
to ‘Luthans and Stewart, 1978’. 


There are perhaps a couple of dozen dropped or incorrect letters and punctuation marks, and the 
typographic style might be a bit different in one or two places of which we are aware, but which we 
do not think need listing. 


Ralph Sprague asked me to add a few comments for the SIGBDP members to putthings in perspective. 
All the changes that have been mentioned could be applied very easily, and the entire issue reprocessed 
in an hour or two, by someone familiar with the UNIX and with access to the material. The SIGOA 
editors, however just do not have the time. We have been producing the Newsletter on a self-help basis, 
with the authors providing input in machine readable form and taking responsibility for its accuracy. 
Our goal has been to produce a functional product, with minimal effort. The technology has been 
extremely effective, and we encourage others to use it. 


For the present issue, SIGBDP could not provide machine readable input, and asked me to get the 
articles retyped appropriately. My younger son, who is now fourteen, did this using a TI 765 and CMS. 
I had some personal reasons for trying to get the issue out of the way in a hurry, and did not give Graham 
or Ralph enough time to check the pre-typeset printouts. On August 15, Brian and I went ahead, on 
a one-shot now-or-possibly-horribly-belated-if-not-quite-never basis, and produced the typeset output 
which is now being published, and Russ Abbott helped with many of the illustrations. The aftermath 
has been an interesting and useful experience to SIGOA and, I trust, to SIGBDP. 


Michael P. Barnett, Editor SIGOA, October 15, 1980 


